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Abstract. Pattern matching is an important feature in various func- 
tional programming languages such as SML, Caml, Haskell, etc. In these 
languages, unreachable or redundant matching clauses, which can be re- 
garded as a special form of dead code, are a rich source for program 
errors. Therefore, eliminating unreachable matching clauses at compile- 
time can significantly enhance program error detection. Furthermore, 
this can also lead to significantly more efficient code at run-time. 

We present a novel approach to eliminating unreachable matching 
clauses through the use of the dependent type system of DML, a func- 
tional programming language that enriches ML with a restricted form of 
dependent types. We then prove the correctness of the approach, which 
consists of the major technical contribution of the paper. In addition, we 
demonstrate the applicability of our approach to dead code elimination 
through some realistic examples. This constitutes a practical application 
of dependent types to functional programming, and in return it provides 
us with further support for the methodology adopted in our research on 
dependent types in practical programming. 

1 Introduction 

There is no precise definition of dead code in the literature. In this paper, we 
refer dead code as the code which can never be executed at run-time. Notice that 
this is essentially different from dead computation [1], that is, the computation 
producing values which are never used. For instance, in the following C code, 

x = 1 ; x = 2 ; 

the part x = 1 is dead computation but not dead code since it is executed but 
its execution does not affect the entire computation. Also dead code is different 
from partially dead code, which is not executed only on some computation paths 
[10]. For instance, the part y = 1 in the following C code is partially dead since 
it is not executed when x is not zero. 

* The research reported in this paper was supported in part by the United States Air 
Force Materiel Command (F19628-96-C-0161) and the Department of Defense. 



if (x == 0) { y = 1; } 

Pattern matching is an important feature in many functional programming lan- 
guages such as Standard ML[12], Caml[16], Haskell [6], etc. A particular form of 
dead code in these languages is unreachable or redundant matching clauses, that 
is, matching clauses which can never be chosen at run-time. The following is a 
straightforward but unrealistic example of dead code in Standard ML. 

exception Unreachable 
fun foo 1 = 

case 1 of nil => 1 | _::_=> 1 I => raise Unreachable 

The function foo is of type ' a list -> 'a list. Clearly, the third matching 
clause in the definition of foo can never be chosen since every value of type 
'a list matches either the first or the second clause. This form of unreachable 
matching clauses can be readily detected in practice. For instance, if the above 
code is passed to the (current version of) SML/NJ compiler, an error message is 
reported describing the redundancy of the third matching clause. However, there 
are realistic cases which are much more subtle. Let us consider the following 
example. 

exception ZipException 
fun zip(nil, nil) = nil 

I zip(x::xs, y: :ys) = (x, y)::zip(xs, ys) 

I zip _ = raise ZipException 

The function zip is meant to zip two lists of equal length into one. This is some- 
what hinted in the program since an exception is raised if two given lists are 
of different lengths. If zip is applied to a pair of lists of equal length, then the 
third matching clause in its definition can never be chosen for the obvious reason. 
Therefore, we can eliminate the third matching clause as long as we can guaran- 
tee that zip is always applied to a pair of lists of equal length. Unfortunately, it 
is impossible in Standard ML (or other languages with similar or weaker typing 
systems) to restrict the application of zip only to pairs of lists of equal length 
since its type system cannot distinguish lists of different lengths. This partially 
motivated our research on strengthening the type system of ML with dependent 
types so that we can formulated more accurate types such as the type of all pairs 
of lists of equal length. 

The type system of DML (Dependent ML ) in [20] enriches that of ML with 
a restricted form of dependent types. The primary goal of this enrichment is to 
provide for specification and inference of significantly more accurate informa- 
tion, facilitating both program error detection and compiler optimization. For 
instance, the following declaration in DML enables the type system to distinguish 
lists of different lengths. 

datatype 'a list = nil I :: of 'a * 'a list 
typeref 'a list of nat with 

nil < I 'a list(0) 
I :: <| {n:nat} 'a * 'a list(n) -> 'a list(n+l) 



The declaration defines a (polymorphic) datatype 'a list to represent the type 
of lists. This datatype is then indexed by a natural number, which stands for 
the length of a list in this case. The constructors associated with the datatype 
'a list are then assigned dependent types: 

— nil <| 'a list(O) states that nil is a list of length 0, and 

— :: <| {n:nat} 'a * 'a list(n) -> 'a list(n+l) states that :: yields 
a list of length n + 1 when given a pair consisting of an element and a list 
of length n. Note that {n:nat> means that n is universally quantified over 
natural numbers, usually written as Un : nat. 

Now the following definition of the zip function in DML guarantees that this 
function can only be applied to a pair of lists of equal length. 

fun('a, 'b) 

zip_saf e(nil, nil) = nil 
I zip_saf e(x: :xs , y::ys) = (x, y) : : zip_saf e (xs , ys) 
where zip_safe <| {n:nat} 'a list(n)*'b list(n)->('a * 'b) list(n) 

The use of f un( ' a, 'b) is a recent feature of Standard ML [12], which allows the 
programmer to explicitly control the scope of the type variables ' a and 'b. The 
type of zip_saf e is {n:nat> 'a list(n) * 'b list(n)->('a * 'b)list(n) 
which states that zip_saf e can only accept a pair of lists of equal length and 
always returns a list of the same length. Notice that the where clause is a type 
annotation which must be provided by the programmer. If this function is applied 
to a pair of lists of unequal lengths, the code cannot pass the type-checking in 
DML and therefore is rejected. In this case, the programmer can certainly choose 
to use the previously defined zip if necessary in order to pass type-checking. 

The programmer often knows that certain matching clauses can never be 
executed if a program is implemented correctly. Therefore, it can lead to pro- 
gram error detection at compile-time if we can verify whether these clauses can 
indeed be eliminated in an implementation. For example, when implementing 
an evaluator for the pure call- by- value A-calculus, we know that we can never 
encounter a variable which is not bound to a closure during the evaluation of 
a closed A-expression. As shown in Section 4.2, this can be readily verified by 
our approach. Eliminating dead code can also lead to more efficient execution 
at run-time. For instance, zip_saf e need not check the tag of the second list in 
its argument since it is always the same as that of the first one, and this can 
contribute to 20% speedup on a Sun Sparc 20 running SML/NJ version 110. 
In general, our approach can be regarded as an example which supports that 
safety and efficiency can be complementary. These advantages yield some strong 
justification for our approach to eliminating unreachable matching clauses at 
compile-time. 

We organize the paper as follows. In Section 2, we give some preliminaries on 
the core of DML, which provides all the machinery needed to establish the cor- 
rectness of our approach to dead code elimination. We then present in Section 3 
the derivation rules which formalize the approach, and prove the correctness of 



these rules. This constitutes the main technical contribution of this paper. In 
Section 4, we use some realistic examples to demonstrate the applicability of our 
approach. The rest of the paper discusses some related work and then concludes. 



2 Preliminaries 

It is both infeasible and unnecessary to present in this paper the entire DML, 
which can be found in [20]. We refer the reader to [18] for an overview of DML. 
The essence of our approach will be fully captured in an core language MLq(C), 
which is a monomorphic extension of mini-ML with general pattern matching 
and universal dependent types. 

Note that the omission of ML let-polymorphism in ML^(C), which is fully 
supported in DML, is simply for the sake of brevity of the presentation. Since 
ML^(C) parameterizes over a constraint domain C from which type index ob- 
jects are drawn, we start with a brief introduction of the formation of a constraint 
domain. 



2.1 Constraint Domains 

We emphasize that the general constraint language itself is typed. In order to 
avoid potential confusion we call the types in the constraint language index sorts. 
We use b for base index sorts such as o for propositions and int for integers. 
A signature E declares a set of function symbols and associates with every 
function symbol an index sort defined below. A E-structure V consists of a 
set dom(D) and an assignment of functions to the function symbols in E. A 
constraint domain C = (E, V) consists of a signature E and a X'-structure V. 

We use f for interpreted function symbols (constants are 0-ary functions), 
p for atomic predicates (that is, functions of sort 7 — » o) and we assume that 
we have constants such as equality, truth values T and _L, conjunction A, and 
disjunction V, all of which are interpreted as usual. 

index sorts 7 ::= b | 1 | 71 * 72 | {a : 7 | P} 

index propositions P ::= T | _L | p(i) | P Y A P 2 | P 1 V P 2 

Here {a : 7 | P} is the subset index sort for those elements of index sort 7 
satisfying proposition P, where P is an index proposition. For instance, not is 
an abbreviation for {a : int \ a > 0}, that is, nat is a subset index sort of int. 

We use a for index variables in the following formation. We assume that there 
exists a predicate = of sort 7 * 7 — >• o for every index sort 7, which is interpreted 
as equality. Also we emphasize that all function symbols declared in E must be 
associated with index sorts of form 7 — > b or b. In other words, the constraint 
language is first-order. 



index objects i,j 

index contexts <f> 

index constraints # 

index substitutions 6 



a I f(i) I () I I fst(i) I snd(i) 
■ind I </>,a : 7 I </>,P 

i = j I T I $ x A # 2 I P 3 # I Va : 7.* | 3a : 7.* 
D I * [a -> i] 



satisfiability relation </>[=# 



Note -ind is for the empty index context. We omit the standard sorting rules for 
this language for the sake of brevity. The satisfiability relation <f> |= # means 
that (<t>)$ is satisfiable in the domain dom(D) of the ^-structure V, where {<}>)$ 
is defined as follows. 

(■ind)* = * 

(a : b)$ = Va : b.$ 

(a : 71 *7 2 )# = (a x : 7i)(a 2 : 7 2 )*[a i-» (01,02)] 
(0,{a: 7 |P})# = (0)(a:7)(PD#) 
(^)* = M(P3*) 

In this paper, we are primarily interested in the integer constraint domain, 
where the signature I7i nt is given in Figure 1 and the domain of Z^-structure is 
simply the set of integers. For instance, let <f> = n : not. a : nat, a + 1 = n, 0 = n, 
then <f> |= ± holds in this domain since (^)-L. defined as follows, is true. 

Vn : int.n > 0 D Va : int.a > 0 D (a + 1 = n D (0 = n D _L)) 

Basically, a+1 = n implies n > 0 since a is a natural number, and this contradicts 
0 = n. In other words, the index context <j) is inconsistent. This example will be 
used later. 



S int = abs 

rain 
< 
> 



Fig. 1. The signature of the integer domain 



2.2 The Language ML" (C) 

Given a constraint domain C, the syntax of ML^(C) is given in Figure 2. The 
syntax is relatively involved because we must include general pattern matching 
in order to present our approach. This is an explicitly typed language since the 
dead code elimination we propose is performed when type-checking a program 
is done and an explicitly typed version of the program has been constructed. 

We use S for base type families, where we use 5(Q) for an unindexed type. 
Also we use 'ms, *ind and • for empty matches, empty index context and empty 
context, respectively. The difference between values and value forms is that the 
former is only closed under value substitutions while the latter is closed under 
all substitutions. We write e[i] for the application of an expression to a type 
index and Aa : j.e for index variable abstraction. 



int —¥ int sgn : int — > int + : int * int — > int 

int * int — > int * : int * int —¥ int div : int * int —¥ int 

int * int — > int max : int * int —¥ int mod : int * int —¥ int 

int * int — > o < : int * int — > o = : int * int — > o 

int * int — > o > : int * int — > o ^ : int * int — > o 



tamilies 


X 
0 


:= (family of refined datatypes) 


signature 


S 


:= - S ig | S,5 : 7 -> * 






I c n n £ ( '\ 

\S,c: Ilai : 71 . . . lla n : j„.d(i) 






\S,c: Ilai : 71 . . . lla n : j„.t -»■ d(i) 


types 


T 


:= byi) \ 1 | (ti * T2J | (Ti — > Ti) \ (11a : 7.TJ 


patterns 


V 


iri r iiri r i / \ i /\ i / \ 

:= x \ c[ai] . . . [a n ] \ c[ai] . . . [a„](p) | () | (pi,p 2 ) 


matches 


ms 


:= -ms 1 (p => e | ms) 


expressions 


e 


:= a; 1 () 1 (ei, e2) 1 c[ii] . . . \i n ] 1 c[ii] . . . finlfe) 






| (case e of ms) (lam x : r.e) | ei(e2) 






| let x = ei in e 2 end | (fix / : t.u) 






(Aa : 7.e) | e[i] 


value forms 


u 


:= c[ii] . . . [i n ] | c[h] . . . [i„](u) | () | («i,« 2 > 






| (lam x : r.e) (Aa : 7.1*) 


values 


V 


:= z | c[h] . . . [i n ] | c[h] . . . [i n ]{v) | () | {V!,V 2 ) 






| (lam x : r.e) (Aa : 7.11) 


contexts 


r 


:= ■ | r, x : T 


index contexts 




:= -ind \<t>, a : 7 \<j), P 


substitutions 


6 


■= D 1 0[x h-> e] | 6>[a h-> i] 



Fig. 2. The syntax for ML?(C) 



We leave out polymorphism in ML 0 (C) because polymorphism is largely 
orthogonal to the development of dependent types and has little effect on the 
dead code elimination presented in this paper. This tremendously simplifies the 
presentation. 

In the rest of the paper, we assume that datatypes intList (for integer lists) 
and intPairList (for integer pair lists) have been declared with associated con- 
structors intNil, intCons and intPairNil, intPairCons, respectively, and re- 
fined as follows. 

intNil : intList(0) 

intCons : Pin : nat.int * intList(n) — > intList(n + 1) 
intPairNil : intPairList(0) 

intPairCons : Pin : nat.iint * int) * intPairList(n) — > intPairList(n + 1) 

However, we will write nil for either intNil or intPairNil and cons for either 
intCons or intPairCons if there is no danger of confusion. The following expres- 
sion zipdef in ML^(C) corresponds a monomorphic version of the previously 
defined function zip_safe (we use b for an index variable here). 

fix zip : Pin : nat.intList(n) * intList(n) — > intPairList(n). 
An : nat. lam I : intList(n) * intList(n). 
case I of (nil, nil) nil 

I (cons[a](x, xs), cons[b](y, ys)) => cons[a]((x, y), zip[a](xs, ys)) 



Static Semantics We use 0 |= r = t' for the congruent extension of 0 \= i = j 
from index objects to types, which is determined by the following rules. 



<t> 1= i = j 
0 |= S(i) = S(j) 

<P\=t[=Ti 4>\=T 2 =T2 
0 |= Ti T 2 = T[ 



(f>\=n =T[ 0 |= T 2 = Tl, 

0 l = T l * T 2 = T"i * 7"2 

0, a : 7 |= t = t' 
0 |= i7a : 7-T = LTa : 7 .t' 



We start with the typing rules for patterns, which are listed in Figure 3. These 
rules are essential to the formulation of our approach to eliminating unreachable 
matching clauses. The judgment p 4- r [> (0: V) expresses that the index and 
ordinary variables in pattern p have the sorts and types in 0 and J 1 , respectively, 
if we know that p must have type t. 



pi in > (0i;J\) p 2 J,r 2 > (<p2-,r 2 ) 

(pat-prod) 



(pi,P2) J. Tl * T 2 > (01, 02! A, r 2 ) 
5(c) = iTai : 71 . . . iTa„ : 7 n -5(i) 
c[ai] . . . [a n ] I 5(j) > (ai : 71, . . . ,a n : j n ,i = j 
<S(c) = Tla\ : 71 . . . Tla n : 7 „.(t S(i)) p j t > (0; F) 
c[ai] . . . [a„](p) J. > (ai : 71,. . . ,a„ : 7 „,i = j, 0; F) 



(pat-cons-wo) 
(pat-cons-w) 



Fig. 3. Typing rules for patterns 



We omit the rest of typing rules for ML 0 (C), which can be found in [20]. 
The following lemma is at the heart of our approach to dead code elimination. 

Lemma 1. (Main Lemma) Suppose that p J, r \> 0: F is derivable and 0 |= ± 
satisfiable. If -i nc i; • h v : t is derivable, then v does not match the pattern p. 

Proof. The proof proceeds by structural induction on the derivation of p I r X> 
0; r. We present one interesting case where p is of form c[ai] . . . [a n ](p') for some 
constructor a Then the derivation of p I r > 0; F must be of the following form. 

<S(c) =n ai : 7l ...Z7a„ : 7 „.(t' -><*(»)) p'|r'>(0';r) 
(pat-cons-w) 

c[ai] . . . [a„](p') J, <5(j) > (ai : 7 i,. . .,a„ : 7 „,i = j,0';F) 

where r = <5(j), 0 = ai : 7 i, . . . , a„ : 7n , j = j, 0'. Assume that i> matches p. 
Then i> is of form c[ii] . . . [i n ](v'), v 1 matches p' and \~ ik ■ Jk are derivable for 
1 < k < n. Since c[ii] . . . is of type S(i[8]) for 9 = [ai H- «i , . . . , a„ H- i„], 

•ind |= = j is satisfiable. This leads to the satisfiability of <j>'[6] \= -L since 



<j> \= _L is satisfiable. Notice that we can also derive -jnd; • \~ v' : t'[9] and 
p' I t'[9] t> ((j)'[6],r[6]). By induction hypothesis, v' does not match p' . This 
yields a contradiction, and therefore v does not match p. 
All other cases can be treated similarly. 

Dynamic Semantics The operational semantics of ML^(C) can be given as 
usual in the style of natural semantics [9]. Again we omit the standard evalu- 
ation rules, which can be found in [20] 

We use e <— »d v to mean that e reduces to a value v in this semantics. These 
evaluation rules are only needed for proving the correctness of our approach. 
The following type-preservation theorem is also needed for this purpose. 

Theorem 1. (Type preservation in MLq(C)) Given e,v in MLq (C) such that 
e <— >d v is derivable. If -ind! • I - e : r is derivable, then -ind! • \~ v : t is derivable. 

Proof. Please see Section 4.1.2 in [20] for details. 

Notice that there is some nondeterminism associated with the rule for evalu- 
ating a case statement. If more than one matching clauses can match the value, 
there is no order to determine which one should be chosen. This is different from 
the deterministic strategy adopted in ML, which always chooses the first one 
which matches. We shall come back to this point later. 

2.3 Operational Equivalence 

In order to prove the correctness of our approach to dead code elimination, we 
must show that this approach does not alter the semantics of a program. We 
introduce the operational equivalence relation = as follows for this purpose. 

Definition 1. We present the definition of contexts as follows. 

(matching contexts) C m ::= | (p => C \ ms) \ (p e C m ) 

(contexts) C ::= [] | (C, e) | (e, C) | c(C) | lam x : t.C \ C(e) | e(C) 

| case C of ms \ case e of C m \ fix f : t.C 
| let x = C in e end | let x = e in C end 

Given a context C and an expression e, C\e] stands for the expression formulated 
by replacing with e the hole [] in C . We emphasize that this replacement is 
variable capturing. 

Definition 2. Given two expression e\ and in MLq(C), e\ is operationally 
equivalent to ei if the following holds. 

— Given any context C such that -ind!" I - C[ej] : 1 are derivable for i = 1,2, 
C[ei] >d () is derivable if and only if C[e2\ >d () is. 

We write e\ = if e.\ is operationally equivalent to e^. 

Clearly = is an equivalence relation. Our aim is to prove that if a program e 
is transformed into e after dead code elimination, the e = e. In other words, 
we intend to show that dead code elimination does not alter the operational 
semantics of a program. 



3 Dead Code Elimination 



We now go through an example to show how dead code elimination is performed 
on a program. This approach is then formalized and proven correct. This con- 
stitutes the main technical contribution of the paper. 

3.1 An Example 

Let us declare the function zip_saf e in DML as follows. 

fun zip_saf e (intNil , intNil) = intPairNil 

I zip_saf e(intCons(x,xs) , intCons(y,ys)) = 
intPairCons((x, y) , zip_safe(xs, ys)) 

I zip_safe _ = raise ZipException 
where zip_safe <| {n:nat} intList (n) *intList (n) ->intPairList (n) 

This declaration is then elaborated (after type-checking) to the following expres- 
sion m ML^(C) (we assume that raise(ZipException) is a legal expression). 
Notice that the third matching clause in the above definition is transformed into 
two non- overlapping matching clauses. This is necessary since pattern matching 
is done sequentially in ML, and therefore the value must match either pattern 
(intNil, intCons (_ , _) ) or (intCons (_ , _) , intNil) if the third clause is 
chosen. The approach to performing such a transform is standard and therefore 
omitted. 

fix zip : Un : nat.intList(n) * intList(n) — > intPairList(n). 
An : nat. lam I : intList(n) * intList(n). 
case I of (nil, nil) nil 

| (cons[a](x,xs),cons[b](y,ys) => cons\a]((x, y), zip[a](xs, ys)) 
| (nil,cons[b](y,ys)) =>• raise(ZipException) 
| (cons[a](x,xs),nil) raise(ZipException) 

If the third clause in the above expression can be chosen, then (nil, cons[b](y, ys)) 
must match a value of type intList(n) * intList(n) for some natural number 
n. Checking (nil,cons[b](y,ys)) against intList(n) * intList(n), we derive the 
following for cf> = (0 = n, b : nat, b + 1 = n). 

(nil, cons[b](y, ys)) 1 intList(n) * intList(n) \> (4>\y : int. ys : intList(b)) 

Notice that 0 is inconsistent since <f> |= _L is satisfiable. Therefore, we know by 
Lemma 1 that the third clause is unreachable. Similarly, the fourth clause is also 
unreachable. We can thus eliminate the dead code when compiling the program. 

3.2 Formalization 

While the above informal presentation of dead code elimination is intuitive, 
we have yet to demonstrate why this approach is correct and how it can be 



r(x) = r 

(ehm-var) 



(f>; r h x : t ^> x 

s{c) = n~£ : -f.5(i) 



4>\ r h c[ i ] : 5(i[tf h-> i ]) > c[ i ] 
5(c) = J7 # : t^.t -> c$(i) ^The: r[rf >-> ~t] > e 



; r h c[ T ](e) : <5(i[^ ^ T ]) > c[T](e) 

*;rh <>:!><> ( elim " Unit ) 

^ f h ei : Ti » ei P h e2 : T2 S> ei 



(elim-cons-wo) 

(elim-cons-w) 



<j>',r \- (ei, ei) : ri * T2 S> (ei_, £2) 
0 h _T[ctx] <j> h n => T2 



(elim-prod) 



: n =>• T2 3> 

p I ri >((/>'; T') 0, f />'; T, T' h e : t 2 >e 4>; T \- ms : n => r 2 > ms 



</>: -T h (p =>• e ms) : ri => r 2 ^> (p => e | ms) 
p J, ti > {cj>';r') (/>,(/>' \=- d>: r h ms : n =>■ t? > ms 
0; I 1 h (p => e | ms) : ti =>• r2 3> ms 
i4: f h e : ri > e 0: _T h ms : Ti => T2 3> ms 



(elim-mat-empty) 

n,s 

(elim-mat) 



(elim- mat-dead) 



: r h case e of ms : T2 ^> case e of ms 
:7;fl- e : t > e 



(elim-case) 



; _T h Aa : 7.e : (J7a : j.t) ^> Aa : 'y.e 
<f>-,r\-e: Tla : j.t S> e </> h i : 7 



(elim-ilam) 



^Th e[i] : r[a h-> i] > e[i] ( ellm " la PP) 

1/1: f. 1 : ti h e : T2 > e 
lam x : Ti.e : Ti — > Ti S> lam x : Ti.e 
<^>: r h ei : ri — )• T2 3> ei_ ^ f h e2 : T2 > £2 
0; r h ei(e2) : T2 S> ei_(e2) 
<^>: i" 1 h ei : n ^> ei_ 0; P. a : n h e2 : T2 ^> e 2 
; P h let x = ei in ei end : T2 S> let x = e\ in e2 end 
cf>; r, f : t \- u : t ^> u 



(elim- let) 



6; r h (fix / : t.m) : t 3> fix / : t.u 



(elim-fix) 



Fig. 4. The rules for dead code elimination 



implemented. For this purpose, we formalize the approach with derivation rules. 
A judgment of form <f>: r h e : t S> e means that an expression e of type t 
under <j>\ r transforms into the expression e through dead code elimination. The 
rules for deriving such a judgment are presented in Figure 4. Notice that the 
rule (elim-mat-dead) is the only rule which eliminates dead code. 

Proposition 1. We have the following. 

1. If 4>; r h e : r is derivable, then 0; r h e : r ^> e is a/so derivable. 

2. if 4>; r h e : r ^> e and -ind! ■ I - C[e] : 1 are derivable, then •;„<]: ■ I - C[e] : 1 ^> 
C[e] «s also derivable. 

3. If <p: r \- e : t e is derivable, then both <f>\ r h e : r and <fi: T \- e : t are 
derivable. 

Proof. (1) and (2) are straightforward, and (3) follows from structural induction 
on the derivation of (j>; r h e : r > e. 

Proposition 1 (1) simply means that we can always choose not to eliminate any 
code, and (2) means that dead code elimination is independent of context, and 
(3) means that dead code elimination is type-preserving. 

Lemma 2. (Substitution) 

1. If both 4>\ r. x : Ti h e\ : T\ S> ei and <j>\ r h e2 : T2 S> £2 are derivable, then 

so is 4>\T h ei [a; h-> 62] : Ti S> ei [a; h-> £2] . 
,8. 7/ ioi/i fa : 7;f h e : t » e and </> h i : 7 are derivable, then so is 

<j>; r[a h-> 2] h e[a h-> 2] : r[a h-> 2] 3> e[a h-> 2']. 

Proof. (1) and (2) follow from structural induction on the derivations of 4>',r,x : 
T<i h e\ : T\ ^> e\_ and <f>, a : 7; r h e : r ~S> e, respectively. 

Lemma 3. Assume that -ind! ■ I" e : t > e is derivable. 

1. If e >d i> is derivable, then e <— »d w «s derivable for some v such that 
•ind! • I - w : t ^> w is ateo derivable. 

2. If e >d w is derivable, then e <— »d u «s derivable for some v such that 
•ind! • I - w : t ^> w is ateo derivable. 

Proof. (1) and (2) follow from structural induction on the derivations of e <— i> 
and e >d respectively, using both Lemma 1 and Lemma 2. 

Theorem 2. If (f>; T \- e : t ^> e is derivable, then e = e holds. 

Proof. Let C be a context such that both - m< j L ; ■ h C[e] : 1 and C[e] >d {) are 
derivable. By Proposition 1, -ind!' I - C[e] : 1 ^> C[e] is derivable. Hence, by 
Lemma 3 (1), C[e] <— »d w is derivable for some w such that -ind; ■ h () : 1 > o, 
This implies that wis {) . Similarly, by Lemma 3 (2) , we can prove that C[e] () 
is derivable for every context C such that both - m< j L : i ■ h C[e] : 1 and C[e] ^-»d () 
are derivable. Therefore, e = e holds. 



4 Examples 



We present some realistic examples in this section to demonstrate the effect 
of dead code elimination through dependent types. Note that polymorphism is 
allowed in this section. 

4.1 The nth function 

When applied to (l,n), the following nth function returns the nth element in 
the list I if n is less than the length of / and raises the Subscript exception 
otherwise. This function is frequently called in functional programming, where 
the use of lists is pervasive. 

fun nth (nil, _) = raise Subscript 

I nth(x::xs, n) = if n = 0 then x else nth(xs, n-1) 

If we assign nth the following type, that is, we restrict the application of nth to 
pairs (l,n) such that n is always less than the length of I, 

{len:nat}{index:nat | index < len} 'a list(len) * int(index) -> 'a 

then the first matching clause in the definition of nth is unreachable, and there- 
fore can be safely eliminated. Note that we have refined the built-in type int into 
infinitely many singleton types such that int (n) contains only n for each integer 
n. Let us call this version nth_safe, and we have measured that nth_saf e is 
about 25% faster than nth on a Sparc 20 station running SML/NJ version 110. 
The use of a similar idea to eliminate array bound checks can be found in [17]. 

4.2 An Evaluator for the Call-By- Value A-Calculus 

The code in Figure 5 implements an evaluator for the pure call-by-value A- 
calculus. We use de Bruijn's notation to represent A-expressions. For example, 
Xx.Xy.y(x) is represented as Lam(Lam(App(0ne , Shift (One) ) ) ) . We then refine 
the datatype lambda_exp into infinitely many types lambda_exp (n) . For each 
natural numbers n, lambda_exp(n) roughly stands for the type of all A-terms in 
which there are at most n free variables. 

If a value of type lambda_exp(n) * closure list(n) for some n matches 
the last clause in the definition of cbv then it matches either pattern (One , nil) 
or pattern (Shift _, nil). In either contradiction is reached since a 

value which matches either One or Shift _ can not be of type lambda_exp(0) 
but nil is of type closure list(O). Therefore, the last clause can be safely 
eliminated. 

The programmer knows that the last clause is unreachable. After this is 
mechanically verified, the programmer gains confidence in the above implemen- 
tation. On the other hand, if the last clause could not be safely eliminated, it 
would have been an indication of some program errors in the implementation. 



datatype lambda_exp = 

One I Shift of lambda_exp I 

Lam of lambda_exp I App of lambda_exp * lambda_exp 
datatype closure = Closure of lambda_exp * closure list 

typeref lambda_exp of nat 

with One <| {n:nat} lambda_exp(n+l) 

I Shift <| {n:nat} lambda_exp(n) -> lambda_exp (n+1) 

I Lam <| {n:nat} lambda_exp(n+l) -> lambda_exp (n) 

I App <| {n:nat} lambda_exp(n) * lambda_exp (n) -> lambda_exp(n) 

I Closure <| {n:nat} lambda_exp (n) * closure list(n) -> closure 

exception Unreachable 

fun callbyvalue (exp) = let 
fun cbv(0ne, clo::_) = clo 

I cbv (Shift (exp) , _::env) = cbv(exp, env) 
I cbv (exp as Lam _, env) = Closure (exp, env) 
I cbv(App(expl , exp2) , env) = let 

val Closure (Lam(body) , envl) = cbv(expl, env) 
and clo = cbv(exp2, env) 
in cbv(body, clo::envl) end 
I cbv _ = raise Unreachable (* this can be safely eliminated *) 
where cbv <| {n:nat} lambda_exp (n) * closure list(n) -> closure 

in 

cbv (exp, nil) 
end 

where callbyvalue <| lambda_exp(0) -> closure 

(* Note: callbyvalue can only apply to CLOSED lambda expressions *) 
Fig. 5. An evaluator for the call-by- value A-calculus 

4.3 Other Examples 

So far all the presented examples involve the use of lists, but this is not neces- 
sary. We also have examples involving other data structures such as trees. For 
instance, the reader can find in [19] a red/black tree implementation containing 
unreachable matching clauses which can be eliminated in the same manner. In 
general, unreachable matching clauses are abundant in practice, of which many 
can be eliminated with our approach. 

5 Related Work and Conclusion 

It is beyond reasonable hope to mention even a moderate amount of research 
related or similar to dead code or dead computation elimination because of the 
vastness of the field. The reader can find further references in [8,1,7,13,10, 



14, 11, 15]. Our approach to dead code elimination differs significantly from the 
previous approaches in several aspects. 

We have adopted a type-based approach while most of the previous ap- 
proaches are based on flow analysis. This gives us a great advantage when the 
issue of crossing module boundaries is concerned. For instance, after assigning 
the zip function the type 

{n:nat} 'a list(n) * 'b list(n) -> ('a * 'b) list(n) 

and eliminating the dead code, we can use this function anywhere as long as type- 
checking is passed. On the other hand, an approach based on flow analysis usually 
analyzes an instance of a function call and check whether there is dead code 
associated with this particular function call. One may argue that our approach 
must be supported by a dependent type system while an approach based on flow 
analysis need not. However, there would be no dead code in the zip function if we 
had not assigned it the above dependent type. It is the use of a dependent type 
system that enables us to exploit opportunities which do not exist otherwise. 

Also we are primarily concerned with program error detection while most of 
the previous approaches were mainly designed for compiler optimization, which 
is only our secondary goal. Again, this is largely due to our adoption of a type- 
based approach. 

We emphasize that our approach must rely on the type annotations supplied 
by the programmer in order to detect redundant matching clauses. It seems 
exceedingly difficult at this moment to find a procedure which can synthesize 
type annotations automatically. For instance, without the type annotation in 
the zip_saf e example, it is unclear whether the programmer intends to apply 
the function to a pair lists of unequal lengths, and therefore unclear whether the 
last matching clause is redundant. 

Our approach is most closely related to the research on refinement types [4, 
2], which also aims for assigning programs more accurate types. However, the 
restricted form of dependent types in DML allows the programmer to form types 
which are not captured by the regular tree grammar [5], e.g., the type of all pairs 
of lists of equal length, but this is beyond the reach of refinement types. The 
price we pay is the loss of principal types, which may consequently lead to a 
more involved type-checking algorithm. 

We have experimented our approach to dead code elimination in a prototype 
implementation of a type-checker for DML. We plan to incorporate this approach 
into the compiler for DML which we are building on top of Caml-light. Clearly, 
our approach can also be readily adapted to detecting uncaught exceptions [21], 
and we expect it to work well in this direction when combined with the approach 
in [3]. We shall report the work in the future. 
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